Kibbi Keeper

Kibbi Keeper is a creature-collecting adventure game focused on puzzle solving and shepherding your Kibbi’s through 3 different biomes.

Engine:

Unreal Engine 4

Role:

Lead Level Designer

Development Time:

5 Months

Team Size:

15 Person Team (3 Level Designers)

Download on Steam

My Contributions

As Lead Level Designer with 2 designers under me, I oversaw all planning, documentation, and implementation related to gameplay and narrative design. This consisted of working closely with my team and the Game Director to fully realize the vision of the game.

Game Architecture:

During pre-production and production, I was tasked with setting up the architecture of the game itself. I developed the naming convention we would use for the World Outliner as well as set up the level streaming system my designers and I would be using. I managed the level streaming well into production, even creating a Level Streaming page on our internal Wiki that other disciplines could reference when working inside the scene.

Trigger System:

The other architectural consideration was the game logic itself. With multiple puzzles prototyped on paper or in-engine during pre-production, it was my job to work with the programmers and develop a higher-level Trigger system that designers could implement. What we ended up with were two types of triggers (single step or multiple steps) that would send a message to an Unreal Sequence to play (i.e. a door opening, an elevator rising, etc.). So as designers, our workflow looked like:

Drop desired trigger in Scene (single or multiple step)
Point the trigger to the pressure plate or other stimuli (i.e. lever)
Pick what conditions satisfy the trigger (i.e. an ice Kibbi, two fire Kibbis, the player, etc.)
Point the trigger to the appropriate Unreal Sequence

The pressure plate raising and lowering an elevator using the trigger system

Tutorial:

Additionally, I was responsible for the tutorial from concept to shipping. The tutorial underwent several major changes, most notably a simplification of taming the first Kibbi. This helped standardize the taming mechanic across the game. Some of the axioms driving the tutorial (and tutorial refinement) were:

We felt the Kibbi running from the player and/or attacking them reinforced the wrong message about the tone of the game
Getting the player to see the consequences of their actions with respect to commanding the Kibbi to move is imperative
Make the first puzzle easy enough the player can deduce what to do but not so easy it can be completed entirely on accident
As a player, you know where your Kibbi is, even if it is not following you at that moment

Another development challenge we worked on into Alpha was how we teach the player. The team and I were keen on keeping the UI diegetic so we would not pull the player out of the experience. I worked with our UI programmer and the artists to develop a few prototypes, but ultimately, we ended up with a “pop-up” style tutorial. We found the level of retention among players was far higher when we physically stopped them (albeit briefly) from playing. Also this method of teaching the player complemented the tablet collectible system we had already implemented on the narrative side.

Afterthoughts

What Went Well

We shipped the game. I am proud of everyone on the team and the effort they put in. Every discipline gave it their all and I think we made a strong product as a result.

Inclusive team environment – Everyone felt comfortable going to other disciplines or their respective leads with issues and ideas. Every major design change during production involved all teams affected.

The Feature List. The game direction changed significantly between Vertical Slice and Alpha. This made people uneasy about future workload, so we published the Feature list to everyone on the team and had open discussions about what to cut and what to keep. We had a “lockdown” date in Alpha for the features list. Once it was locked down everyone felt more at ease about the last remaining milestones and the direction of the game.

What Went Wrong

Pipeline issues.

Early on in development features were being added when some disciplines had never heard them mentioned.

This created a lot of stress, not only about the workload, but about the direction of the game itself.

What I Learned

It is easy to become blind to the issues in your own work. I had my two designers swap and play each other’s work and we discovered a multitude of bugs. I should have had them swap even earlier in development, as I think we could have polished and iterated even more.

How to manage the flow of information as a leader. There were times where I was too upfront with my team, discussing features that we (as a lead team) had merely brainstormed earlier that day. There were other times where I did not see the design implication of a change and thus did not inform my team of it, until they later realized it themselves.

While the Feature List alleviated this somewhat, I learned that inundating the people on my team with every bit of information or potential change takes away from their ability to focus on their work.
On the other hand, I became more adept at learning what was likely going to change and what wasn’t based on the tone in the lead meetings. This helped further my rapport with the design team when I could go to them and say “hey X feature is probably going to change, which would impact your design in these ways. So, it’s something to keep an eye on this week.”